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(54) Routing and bandwith allocation 

(57) In a telecommunications system a method of 
routing calls and allocating circuits between a switching 
node and another switching node or between a switch- 
ing node and a switching network, comprises the steps 
of: 

a) allocating each circuit between a pair of nodes or 
between a node and a switching network to a spe- 
cific Net Way which Net Way represents a collection 
of channels grouped together into a logical unit for 
the purpose of bandwidth management: 

(b) creating a Traffic Type decode table at each 
node for deriving the traffic type of those incoming 
calls that, according to a signalling service, are not 
already attributed a traffic type: 

(c) creating a Routing Choices table for associating 
each Net Way with specific destinations: 



(d) creating a Routing Preferences table for associ- 
ating each Routing Choice with a preference rating 
for each traffic type. 

(e) creating a Route Restriction Groups table where 
each record defines a set of Route Restriction Class 
element values and specifies whether the set is 'al- 
lowed' or 'barred' according to that group. 

(f) creating a Bandwidth Limits table where each 
record associates a Net Way with a particular traffic 
type and defines a reserved bandwidth level and a 
maximum bandwidth level for calls of that traffic 
type on that Net Way. 

(g) allocating calls, with reference to their traffic 
type, to a Net Way determined by Routing Choice, 
Routing Preference, and on which a sufficient band- 
width exists. 



Fig. 1 . 



CM 
< 
CM 

O) 

00 
CD 

o 

UJ 



Printed by Jouve 75001 PARIS (FRi 



BEST AVAILABLE COPY 



BNSOOCIO: <EP 0798942A2> 




EPO 



Description 

The present invention relates to intelligent routing 
and bandwidth allocation mechanisms that take placed 
with a telecommunication system comprising a Network 
Service Manager (NSM) and NSM nodes. 

According to the present invention there is provided 
a method of routing calls and allocating circuits in a tel- 
ecommunications system between a switching node 
and another switching node or a switching network com- 
prising the steps of :- 

(a) allocating each circuit between a pair of nodes 
or between a node and a switching network to a 
specific Net Way which Net Way represents a col- 
lection of channels grouped together into a logical 
unit for the purpose of bandwidth management: 

(b) creating a Traffic Type decode table at each 
node for deriving the traffic type of those incoming 
calls that, according to a signalling service, are not 
already attributed a traffic type: 

(c) creating a Routing Choices table for associating 
each Net Way with specific destinations: 

(d) creating a Routing Preferences table for associ- 
ating each Routing Choice with a preference rating 
for each traffic type. 

(e) creating a Route Restriction Groups table where 
each record defines a set of Route Restriction Class 
element values and specifies whether the set is 'al- 
lowed' or "barred" according to that group. 

(f) creating a Bandwidth Limits table where each 
record associates a Net Way with a particular traffic 
type and defines a reserved bandwidth level and a 
maximum bandwidth level for calls of that traffic 
type on that Net Way. 

(g) allocating calls, with reference to their traffic 
type, to a Net Way determined by Routing Choice, 
Routing Preference, and on which a sufficient band- 
width exists. 

The present invention will now be described by way 
of example, with reference to the accompanying draw- 
ings, in which: 

Figure 1 shows a block diagram of a node/network 
service manager configuration; 
Figure 2 shows a block diagram of a network includ- 
ing Net Ways; 

Figure 3 shows a modified Figure 2 including a table 
illustrating the characteristics of the links: 
Figure 4 shows a modified Figure 2 including a table 
of Routing Preferences: 
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Figure 5 shows an illustration of Route Restriction 
Groups: 

Figure 6 shows a block diagram of basic call 
processing. 

5 

The present invention provides an intelligent soft- 
ware controlled interface between customer premises 
equipment and the public and private network domains 
by providing control at the node level. It is capable of 
'0 dynamic bandwidth management and able to exploit 
current and future network services and tariff differen- 
tials. A typical installation will consist of a number of co- 
operating NSM nodes plus a centralised Network Serv- 
ices Manager. However, the nodes incorporate a sub- 
's stantial level of node management and are capable of 
operating without an NSM although the full advantages 
wilt not then be obtained. 

The essence of the present invention is its ability to 
manage and route voice and data traffic over available 
20 public and private bandwidth in a cost effective and flex- 
ible manner. It will typically be interposed between a 
customer's site and the connected networks. On the site 
side it can be connected to one or more Private Auto- 
matic Branch Exchanges (PABXs) by 2Mbps links and 
25 to data devices, including Local Area Network (LAN) 
routers and Video Conferencing units, by a number of 
N * 64Kbps links. On the network side it is connected to 
one or more public and private networks by 2Mbps links. 
(In appropriate territories there will also be support for 
30 T1 1 ,5Mbps links. 64/56Kbps links, basic rate Integrated 
Services Digital Networks (ISDN) interfaces and X21/V 
35 links). 

A key feature of the nodes is the use of voice com- 
pression from 64Kbps bit rates to a nominal range of 8 

35 to 32Kbps. This enables the use of each of the 64Kbps 
channels of the network 2Mbps links for multiple voice 
calls when they are destined for another site equipped 
with the present invention. Control of such calls is ac- 
complished by in-band signalling between the nodes. 

^0 The use of in-band signalling in this way gives the addi- 
tional benefit of being able to provide private network 
features for voice calls even when the public network is 
used. 

Another major feature is a form of bandwidth aggre- 
ss gation whereby a wideband data call or video call need- 
ing N * 64Kbps bandwidth can be divided into separate 
64Kbps inter-node calls, each routed independently ac- 
cording to channel availability. These calls are then re- 
combined by the node at the destination site. 
so The system uses intelligent routing to make the in- 
ter-node calls by the most desirable route determined 
by the cost and service required. Similar algorithms are 
also used to obtain the most economical routings for 
conventional calls to destinations not equipped with the 
55 present invention. 

The purpose of the NSM is to co-ordinate the nodes 
in a network, pre-allocating or reserving bandwidth for 
different types of traffic, and ensuring that the data upon 
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which the nodes make their routing decisions is correct 
and up-to-date. It is also used to interrogate and config- 
ure individual elements of the network, both nodes and 
links, and to gather statistics for display, call-logging and 
call-billing purposes. 

The interfaces on the system are shown schemati- 
cally in Figure 1: the functionality and in particular the 
mechanisms of specific relevance to the present inven- 
tion are described in further detail below. 

At some level, control must be exercised over every 
call. However, requiring a management evaluation of 
each call would create a prohibitive load on the man- 
agement system and increase call set-up times signifi- 
cantly and this would not allow nodes to route calls au- 
tonomously. In addition, there is often very limited infor- 
mation available about each call, but all calls cannot be 
treated identically. For example, some calls may be al- 
lowed to break out onto a public network, while some 
may not and some calls may demand a high quality of 
service (e.g. the Managing Director's calls) while some 
may not. One solution is to group calls together, accord- 
ing to their characteristics and requirements, into a 
number of disjoint groups known as traffic types. So all 
of the normal voice calls might be grouped together as 
the traffic type "normal voice": all of these calls would 
receive the same level of service. Important calls might 
be grouped together as "high priority voice", and given 
the best available service (with unrestricted public net- 
work access). Other traffic types might be created for 
FAX and modem traffic, LAN interconnection, video con- 
ferencing and voice mail. Each traffic type will have its 
own service profile, and traffic type can be added as new 
services are created. Details of how to decode incoming 
calls can be downloaded to the nodes so that autono- 
mous bandwidth allocation decisions can be made lo- 
cally at a node. Obviously this must be done consistently 
across the network. 

Nodes can only derive traffic type from the informa- 
tion presented in a call set-up message. Management 
facilities are provided for defining meaningful traffic 
types in terms of signalling parameters, including class 
of service, originating line and called party identity, and 
the minimum required transfer capability. 

The traffic type of a particular call is generally de- 
rived once at the first node the call passes through and 
then an indication of the traffic type is carried with the 
call- by the Node Signalling Service (NSS). If a call 
breaks out of the private network and subsequently 
breaks back in. the traffic type may need to be re-de- 
rived. 

Traffic types can then be used as the basis for ap- 
portioning and sharing bandwidth on network links. Net- 
work circuits (i.e. circuits other than those connecting 
directly to customer premises equipment) are grouped 
together into 'Net Ways'. A Net Way is a collection of 
channels grouped together in a logical unit for the pur- 
pose of bandwidth management. A Net Way is a logical 
path between a node and (i) another node or (ii) a 



switching network (possibly via intermediate multiplex- 
ors in either case). (See Figure 2) There may be more 
than one Net Way running in parallel between the same 
two network elements. 

5 For each Net Way a table is configured which indi- 

cates which traffic types are permitted to use it and to 
what extent. Each permitted traffic type on the Net Way 
has specified a reserved amount and a maximum 
amount of bandwidth that can be used on that Net Way. 

io As long as there is free bandwidth available on a given 
Net Way, a prospective outgoing call may use that Net 
Way if the current usage for the call's traffic type on the 
Net Way is below the reserve. Otherwise, the call may 
only use the Net Way if doing so will not infringe any 

is other Traffic Type's reserved bandwidth nor its own max- 
imum bandwidth. This 'bandwidth limits' scheme per- 
mits the partition of Net Ways into circuits reserved for 
particular traffic types and a number of circuits that can 
be shared between certain traffic types. The partitioning 

20 is dynamic because individual circuits are not tied to par- 
ticular traffic types or to the shared pool. (See Figure 3). 

Traffic types are also used for related aspects such 
as bandwidth monitoring. Traffic type is also a factor in 
routing in that it can affect the relative preference be- 

2S tween the possible outgoing routes that can be chosen 
to reach the call's destination (see below). 

A node routes calls according to the 'routing rules' 
which have been downloaded to it from the NSM (or en- 
tered locally via a node console). These comprise: 



30 



35 



regular expression style dialling patterns which rep- 
resent destinations that the node recognises. An in-^ 
coming call with a called number that doesn't match 
any of the dialling patterns cannot be routed and will 
be rejected. 



a 'Routing Choices' table, which details (many to 
many) relationships between Net Ways and desti- 
nations. Each Routing Choice indicates that it is 
40 possible to reach a given destination via a given Net 
Way and specifies any special transformation that 
must be applied to the called number. 

A given Net Way/destination combination can have 
45 a number of correlating Routing Choices, each one 
specifying a different transformation. This situation aris- 
es where source routing is used, e.g. to distinguish be- 
tween multiple Public Switched Network (PSN) carriers 
which can all be reached via the same Net Way. 

so 

a 'Routing Preferences' table which associates 
each Routing Choice with a preference rating per 
traffic type. Thus a particular Routing Choice might 
have a high preference rating for, say. "data", but a 
55 lower preference rating (perhaps even a null pref- 
erence rating) for "video". (See Figure 4) 

a route restriction table consisting of 'Route Restric- 
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tton Groups'. Each Route Restriction Group speci- 
fies a set of 'Route Restriction Class' (RRC) ele- 
ment values (as conveyed by NSS to indicate the 
route restriction class of the caller) that are either 
'allowed' or 'barred'. (See Figure 5) 5 

a table indicating whether each Net Way is gov- 
erned by a Route Restriction Group. 

a table indicating whether each Routing Choice is io 
governed by a Route Restriction Group (independ- 
ently of the associated Net Way). 

The process of routing requires that the call has an 
associated traffic type. It proceeds as follows: f5 

1. The most specific dialling pattern (destination) 
that matches the called number is selected. 

2. All the Routing Choices associated with this des- 20 
tination are selected and ranked in order of their 
preference rating for the call's traffic type (any with 
null preference are not included). 

3. The most preferable Routing Choice from the re- 2s 
suiting set is selected and the following checks are 
applied to it; 

the call must not be barred from using the Rout- 
ing Choice according to its RRC element and 30 
any configured Route Restriction Groups, 
if the Net Way associated with the Routing 
Choice is to a PSN then the call must not carry 
the PSN barred element. 

the Net Way associated with the Routing 3S 
Choice must not be the incoming Net Way. 
there must be free bandwidth available on the 
associated Net Way and, furthermore ; allocat- 
ing any to the call's traffic type must not cause 
a bandwidth infringement on that Net Way. 40 

If any of these checks fail then that Routing 
Choice is removed from the set and the next 
most preferable one is checked. 

4. If a suitable route is found, as much bandwidth J5 
as can be used for the call's traffic type without 
causing a bandwidth infringement may be used by 
the call. 

5. The ranked set of Routing Choices is preserved so 
in case further route attempts need to be attempted 
(e.g. if step back re-routing from a subsequent node 
occurs) by resuming at step 3. The number of re- 
route attempts can be restricted. 

55 

The route restriction test (using the call's RRC ele- 
ment) is an extension of the well known facility and com- 
prises two stages. First, the call is checked to see wheth- 
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er it is permitted to use the prospective Net Way. regard- 
less of the destination called. 

Second, the call is further checked to see whether it is 
permitted to route to the indicated destination using the 
prospective Routing Choice, i.e. using a particular Net 
Way/called number transformation combination. 

As well as relating route restriction tests to Net 
Ways and Routing Choices the other novel feature of 
node route restriction is the ability to configure Route 
Restriction Groups to work according to either a hierar- 
chical or a matrix scheme. (Existing systems using one 
or the other.) The hierarchical scheme is the simplest 
and requires less configuration. Here, RRCs act as 'fa- 
cility restriction levels', whereby each level represents a 
higher level of capability than the preceding level. The 
matrix scheme is more flexible. This treats RRC values 
independently and no one RRC value is considered to 
be better than any other. 

Figure 6 shows an overview of the basic call 
processing. 

In order to fully exploit tariff differentials in PSNs the 
configuration data that comprises the bandwidth alloca- 
tion and routing rules can be programmed to change in 
a scheduled manner. Scheduled changes to bandwidth 
limits can also be used to ensure bandwidth will be avail- 
able at a set time for 'booked calls' such as video con- 
ferences. 

The NSM is used to co-ordinate this programming 
so that the nodes switch configuration simultaneously 
and consistently across the network. The programming 
takes place in advance of the switchover time so that 
communication times between NSM and nodes which 
can vary widely across the network, are not an issue. 
This also permits nodes to continue working to a sched- 
ule should they become disconnected from the NSM. 

In the simplest implementation of the system, the 
schedule that can be held by a node comprises just a 
'current' and a 'next' set of data and a switchover time. 
At the switchover time the next set of data becomes cur- 
rent. After this time NSM would typically download a new 
next set of data and reset the switchover time. Down- 
loading the new data can be in terms of updates to the 
existing data to reduce the communications overhead, 
and the node can be made to simply toggle the current 
and next sets. 

In a more sophisticated implementation, nodes can 
hold multiple sets of configuration data and a repeating 
sequence of switchover times to allow for indefinite pe- 
riods of operation without reconfiguration. 

It is required that a Node Signalling Service (NSS) 
is provided to convey traffic type and other such Node 
specific information from node to node. NSS also pro- 
vides gateway protocol conversion for interfacing to oth- 
er private network equipment (such as PBXs) and public 
switched networks. 

In an (SDN environment, numbers can be received 
and transmitted in a number of different formats, as 
identified by the Numbering Plan Identification (NPI) and 
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Type of Number (TON) fields within various Q.391 infor- 
mation elements. Examples include E.164 international 
E.164 national, E.164 subscriber Private Numbering 
Plan local. Private Numbering Plan level 1 region, etc. 
In addition there is an "implicit" format where the num- s 
bering plan and type of number are implied by the actual 
number digits rather than by the separate NPI and TON 
fields. 

In the case of selection numbers (as conveyed in a 
Q.391 Called party number information element), these '<> 
various receivable forms have to be used for routeing 
and then translated into forms for transmission on to the 
next node. In the case of identification numbers (as con- 
veyed in Q.931 Calling party number and Connected 
number information elements), these various receivable 15 
forms have to be translated into forms suitable for trans- 
mission to the next node. In each case, the actual forms 
that are receivable and the actual forms that it is permis- 
sible to transmit depend on the nature of the interface 
to the adjacent node, e.g. public ISDN access using Q. 20 
931 signalling, leased line using QSIG or DPNSS sig- 
nalling. 

This could therefore result in vast data tables cater- 
ing for all possible translations and routings. 

This has been rationalised by creating a 6-step 2S 
translation process for selection numbers and a 4-step 
translation process for identification numbers. The 
4-step process comprises steps 1, 2, 5 and 6 of the 
6-step process. The 6 steps are: 

30 

Step 1 - Convert a received explicit number form 
into the implicit form (e.g. by adding "9" to the front 
of an E. 164 number); 

Step 2 - Convert a received number from the num- 35 
bering arrangement of the interface concerned into 
a common internal numbering arrangement: 

Step 3 - Optimise the number (e.g. by converting an 

E. 1 64 number for the required destination into a pri- *o 

vate numbering plan equivalent): 



in the Signalling Domain and the Application Domain. 
This isolates from the application software the differenc- 
es between different signalling protocols (e.g. Q.391. 
QSIG, DPNSS, DASS2). 

NSS comprises various messages. The information 
content of each message is divided into three parts. 

a) Application Part - This comprises information that 
is relevant to the Application Domain. Application 
Part information is translated to and from NSS ele- 
ments by the signalling protocol handlers and can 
be examined, modified, inserted or deleted by the 
Application Domain. 

b) Interworking Part - This comprises information 
that is not relevant to the Application Domain but is 
relevant for interworking between different signal- 
ling protocols. Interworking Part information is 
translated to and from NSS elements by the signal- 
ling protocol handlers and passes transparently be- 
tween signalling protocol handlers bypassing the 
Application Domain. This allows interworking of the 
information between different signalling protocols. 
Only information that does not belong to the Appli- 
cation Part and has equivalent in at least two differ- 
ent signalling protocols needs to be put into this 
part. 

c) Transit Part - This comprises information that is 
not relevant to the Application Domain and is not 
needed for interworking between different signalling 
protocols. It is not translated to and from specific 
elements but is passed between signalling protocol 
handlers as elements of the original protocol. This 
Part is suitable for any information that occurs only 
in one protocol and avoids the need for defining 
specific NSS elements for such information. Even 
the signalling protocol handlers do not need to un- 
derstand such elements, i.e. any unrecognised el- 
ements of the signalling protocol can be passed 
through as Transit Part information. 



Step 4 - Convert the destination number in accord- 
ance with the requirements of the selected route (e. 
g. by inserting digits to force selection of a particular 4 & 
carrier): 

Step 5 - Convert a number for transmission from the 
common internal arrangement to the numbering ar- 
rangement of the interface on which it is to be trans- so 
mitted: 

Step 6 - Convert a number for transmission from the 
implicit form into an explicit form acceptable to the 
interface on which it is to be transmitted. 55 

A common interface (Signalling Service, NSS) is 
used between the various signalling protocol handlers 



Claims 

1. A method of routing calls and allocating circuits in 
a telecommunications system between a switching 
node and another switching node or between a 
switching node and a switching network, compris- 
ing the steps of: 

a) allocating each circuit between a pair of 
nodes or between a node and a switching net- 
work to a specific Net Way which Net Way rep- 
resents a collection of channels grouped to- 
gether into a logical unit for the purpose of 
bandwidth management: 



5 



BNSOOCID: <£P 0798942A2> 




EP 0 798 942 



(b) creating a Traffic Type decode table at each 8. 
node for deriving the traffic type of those incom- 
ing calls that according to a signalling service. 

are not already attributed a traffic type: 

5 

(c) creating a Routing Choices table for asso- 9. 
ciating each Net Way with specific destinations: 

(d) creating a Routing Preferences table for as- 
sociating each Routing Choice with a prefer- /o 
ence rating for each traffic type. 




A method as claimed in Claim 7. further including 
provision for creating a rolling schedule comprising 
multiple sets of configuration data and a repeating 
sequence of switchover times. 

A method as claimed in any preceding claim, further 
including provision for monitoring the traffic on 
nodes according to traffic type. 



(e) creating a Route Restriction Groups table 
where each record defines a set of Route Re- 
striction Class element values and specifies is 
whether the set is 'allowed' or 'barred' accord- 
ing to that group. 

(f) creating a Bandwidth Limits tabfe where 
each record associates a Net Way with a par- 20 
ticular traffic type and defines a reserved band- 
width level and a maximum bandwidth level for 
calls of that traffic type on that Net Way. 

(g) allocating calls, with refgrence to their traffic 25 
type, to a Net Way determined by Routing 
Choice, Routing Preference, and on which a 
sufficient bandwidth exists. 



2. A method as claimed in Claim 1 , further comprising 30 
the step of allocating calls : with reference to their 
traffic type, to a Net Way determined by Routing 
Choice, Routing Preference, Route Restriction, and 

on which sufficient bandwidth exists. 

35 

3. A method as claimed in Claim 2, wherein the Route 
Restriction processing is user configurable to oper- 
ate according to a hierarchical or a matrix scheme. 



4. A method as claimed in Claim 2 or 3, wherein a Net -to 
Way is a compressed voice link where each channel 
therein is a sub-rate channel. 



5. A method as claimed in Claim 4, wherein a branch 

of a call occupying a plurality of channels is treated 4$ 
as a call in its own right so that branch catfs can 
proceed independently through the network. 

6. A method as claimed in any preceding claim, where- 
in a network manager controls the configuration of so 
nodes within the network. 



7. A method as claimed in any preceding claim, further 
including provision for creating a scheduled table in 
the nodes for specifying when and in what way 55 
Bandwidth Limits, Routing Preferences and Route 
Restriction data should be changed. 
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